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SMTP Service Extension for 8-bit MIME Transport 


Abstract 
This memo defines an extension to the SMTP service whereby an SMTP 
content body consisting of text containing octets outside of the 
US-ASCII octet range (hex 00-7F) may be relayed using SMTP. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6152. 
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Les 


Introduction 


Although SMTP is widely and robustly deployed, various extensions 
have been requested by parts of the Internet community. In 
particular, a significant portion of the Internet community wishes to 
exchange messages in which the content body consists of a MIME 
message [RFC2045] [RFC2046] [RFC5322] containing arbitrary octet- 
aligned material. This memo uses the mechanism described in the SMTP 
specification [RFC5321] to define an extension to the SMTP service 
whereby such contents may be exchanged. Note that this extension 
does NOT eliminate the possibility of an SMTP server limiting line 
length; servers are free to implement this extension but nevertheless 
set a line length limit no lower than 1000 octets. Given that this 
restriction still applies, this extension does NOT provide a means 
for transferring unencoded binary via SMTP. 


Framework for the 8-bit MIME Transport Extension 
The 8-bit MIME transport extension is laid out as follows: 


1. the name of the SMTP service extension defined here is 
8bit-MIMEtransport; 


2. the EHLO keyword value associated with the extension is 8BITMIME; 


3. no parameter is used with the 8BITMIME EHLO keyword; 


4. one optional parameter using the keyword BODY is added to the 
MAIL command. The value associated with this parameter is a 
keyword indicating whether a 7-bit message (in strict compliance 


with [RFC5321]) or a MIME message (in strict compliance with 
[RFC2046] and [RFC2045]) with arbitrary octet content is being 
sent. The syntax of the value is as follows, using the ABNF 


notation of [RFC5234]: 


body-value = "7BIT" / "8BITMIME" 


5. no additional SMTP verbs are defined by this extension; and 


6. the next section specifies how support for the extension affects 
the behavior of a server and client SMTP. 


The 8bit-MIMEtransport Service Extension 


When a client SMTP wishes to submit (using the MAIL command) a 
content body consisting of a MIME message containing arbitrary lines 
of octet-aligned material, it first issues the EHLO command to the 
server SMTP. If the server SMTP responds with code 250 to the EHLO 
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command, and the response includes the EHLO keyword value 8BITMIME, 
then the server SMTP is indicating that it supports the extended MAIL 
command and will accept MIME messages containing arbitrary octet- 
aligned material. 


The extended MAIL command is issued by a client SMTP when it wishes 
to transmit a content body consisting of a MIME message containing 
arbitrary lines of octet-aligned material. The syntax for this 
command is identical to the MAIL command in RFC 5321, except that a 
BODY parameter must appear after the address. Only one BODY 
parameter may be used in a single MAIL command. 


The complete syntax of this extended command is defined in RFC 5321. 
The esmtp-keyword is BODY, and the syntax for esmtp-value is given by 
the syntax for body-value shown above. 


The value associated with the BODY parameter indicates whether the 
content body that will be passed using the DATA command consists of a 
MIME message containing some arbitrary octet-aligned material 
("8BITMIME") or is encoded entirely in accordance with RFC 5321 
("7BIT"). 


A server that supports the 8-bit MIME transport service extension 
shall preserve all bits in each octet passed using the DATA command. 
Naturally, the usual SMTP data-stuffing algorithm applies, so that a 
content that contains the five-character sequence of 

<CR> <LF> <DOT> <CR> <LF> 

or a content that begins with the three-character sequence of 

<DOT> <CR> <LF> 

does not prematurely terminate the transfer of the content. Further, 
it should be noted that the CR-LF pair immediately preceding the 
final dot is considered part of the content. Finally, although the 
content body contains arbitrary lines of octet-aligned material, the 
length of each line (number of octets between two CR-LF pairs) is 
still subject to SMTP server line length restrictions (which can 
allow as few as 1000 octets, inclusive of the CR-LF pair, on a single 
line). This restriction means that this extension provides the 
necessary facilities for transferring a MIME object with the 8BIT 
content-transfer-encoding, it DOES NOT provide a means of 
transferring an object with the BINARY content-transfer-encoding. 


Once a server SMTP supporting the 8bit-MIMEtransport service 
extension accepts a content body containing octets with the high- 
order (8th) bit set, the server SMTP must deliver or relay the 
content in such a way as to preserve all bits in each octet. 
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If a server SMTP does not support the 8-bit MIME transport extension 
(either by not responding with code 250 to the EHLO command, or by 
not including the EHLO keyword value 8BITMIME in its response), then 
the client SMTP must not, under any circumstances, attempt to 
transfer a content that contains characters outside of the US-ASCII 
octet range (hex 00-7F). 


A client SMTP has two options in this case: first, it may implement a 
gateway transformation to convert the message into valid 7-bit MIME, 
or second, it may treat the barrier to 8-bit as a permanent error and 
handle it in the usual manner for delivery failures. The specifics 
of the transformation from 8-bit MIME to 7-bit MIME are not described 
by this RFC; the conversion is nevertheless constrained in the 
following ways: 


1. it must cause no loss of information; MIME transport encodings 
must be employed as needed to insure this is the case, and 


2. the resulting message must be valid 7-bit MIME. 
4. Usage Example 


The following dialogue illustrates the use of the 8bit-MIMEtransport 
service extension: 


S: <wait for connection on TCP port 25> 

C: <open connection to server> 

S: 220 dbc.mtview.ca.us SMTP service ready 

C: EHLO ymir.claremont.edu 

S: 250-dbc.mtview.ca.us says hello 

S: 250 8BITMIME 

C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME 
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok 
C: RCPT TO:<mrose@dbc.mtview.ca.us> 

S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok 

C: DATA 

S: 354 Send 8BITMIME message, ending in CRLF.CRLF. 
Cae 2 

S: 250 OK 

Cı QUIT 

S: 250 Goodbye 
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3% 


6. 


6. 


Security Considerations 

This RFC does not discuss security issues and is not believed to 
raise any security issues not already endemic in electronic mail and 
present in fully conforming implementations of RFC 5321, including 
attacks facilitated by the presence of an option negotiation 
mechanism. Since MIME semantics are transport-neutral, the 8BITMIME 
option provides no more added capability to disseminate malware than 
is provided by unextended 7-bit SMTP. 

IANA Considerations 
1. SMTP Service Extension Registration 

This document defines an SMTP and Submit service extension. IANA has 
updated the 8BITMIME entry in the SMTP Service Extensions registry, 
as follows: 

Keyword: 8BITMIME 

Description: SMTP and Submit transport of 8-bit MIME content 
Reference: [RFC6152] 

Parameters: See Section 2 in this specification. 
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